
-------- TML Message #879 --------

Archive-Message-Number: 879
Date: Tue, 30 Jan 90 15:53:36 EST
From: ("William B. Morrison") morrison@pyr.gatech.edu
Subject: Star System Digest Volume 2 Issue 1 addendum


Date: Thu, 25 Jan 90 13:07:18
From: Bill Morrison (Coordinator) <morrison@pyr.gatech.edu>
Reply-To: Traveller System Generation Group@pyr.gatech.edu
Subject: Traveller System Generation Group Digest V1 #1 - addendum
To: traveller@dadla.wr.tek.com


Traveller System Generation Thu, 25 Jan 90    Volume 2: Issue:1 - addendum

Today's Topics:
                             Hex mapping algorithm
                          Results of the questionaire
                            Table handling routines


***************************************************************************
** STAR SYSTEM DIGEST: star system generation, storage, and display.     **
** All followups on this topic should be sent to morrison@pyr.gatech.edu **
** They will be edited for clarity and resent to the Traveller Mailing.  **
***************************************************************************

- --------------------------------------------------------------------------------

Date: 15 Jan 90 09:35:34 PST (Mon)
From: jamesp@dadla.wr.tek.com
Subject: Hex mapping algorithm
To: traveller@dadla.wr.tek.com

This article looks appropriate.  My policy is, in general, when someone
posts something to USENET news, it can be redistributed to the list
without explicit permission, as long as it remains completely intact.

- ------- Forwarded Message

> From: Bertil Jonell

Hi!
I remember someone asked about algorithms for hex mapping a while back
There is a posting on that by Jon Watte (d88-jwa@nada.kth.se)
I repost it here and I hope he won't be mad at me (again :-) 

- - ---------------------------------------------------------------------
> Article 1220 of rec.games.programmer:
> Path: mathrt0.math.chalmers.se!chalmers!sunic!draken!d88-jwa
> From: d88-jwa@nada.kth.se (Jon Watte)
> Newsgroups: rec.games.programmer
> Subject: Re: hex map
> Message-ID: <2717@draken.nada.kth.se>
> Date: 13 Jan 90 14:00:57 GMT
> References: <157.25AEE023@metnet.FIDONET.ORG>
> Reply-To: d88-jwa@nada.kth.se (Jon W{tte)
> Organization: Royal Institute of Technology, Stockholm, Sweden
> Lines: 96

> In article <157.25AEE023@metnet.FIDONET.ORG> 
> bwood@f54.n147.z1.FIDONET.ORG (Barry Wood) writes:

>> A friend of mine is interested in any logarithms, etc that might 
>> help him 
				       ~~~~~~~~~~

Algorythms, I presume. (*I* don't have english for native language,
so don't blame my spelling)

2 minutes of thought yields:

A hex map can be represented in a plain 2d array. From now on I
presume you are familiar with hex numbering:

0000        0002        0004
      0001        0003
0100        0102        0104
      0101        0103
0200        0202        0204

etc.

One easily notes that every second column is half a hex lower
down. This is no problem; just raise it:

0000  0001  0002  0003  0004

0100  0101  0102  0103  0104

etc.

Now, to display this array (say, array[X_SIZ][Y_SIZ] of char)
you use the following function:

void
display(a)
char ** a;
{
	int x, y;

	for(y=0; y<Y_SIZ; x++) {
		for(x=0; x<X_SIZ; y++) {
			move(x, x&1 + y*2);
			addch(a[x][y]);
		}
	}
	refresh();
}

if move(x,y) moves x == column, y == row (curses is other way round)

Second problem, movement. Say you are in hex yyxx and want to go
in direction d where 0 = N, 1 = NE, 2 = SE etc. (North == up)
the quick & dirty solution is:

void
move(x, y, d)
int *x, *y, d;
{
	switch(d) {
	case 0:
		*y--;
		break;
	case 1:
		*y -= (*x &1) ? 0 : 1;
		*x++;
		break;
	case 2:
		*y += (*x &1);
		*x++;
		break;
	case 3:
		*y++;
		break;
	case 4:
		*y += (*x &1);
		*x--;
		break;
	case 5:
		*y -= (*x &1) ? 0 : 1;		
		*x--;
		break;
	default:
		/* Invalid move */
		;
	}
}

Of course, you'll want to check against movements running of
the map too... :-)

These functions do everything for you - it isn't any harder
than that !

h+
- - -- 
   ---  Stay alert !  -  Trust no one !  -  Keep your laser handy !  ---
             h+@nada.kth.se  ==  h+@proxxi.se  ==  Jon Watte
                    longer .sig available on request

- ------- End of Forwarded Message

- ------------------------------

Date: Fri, 17 Nov 89 11:34:38 EST
From: Dan Corrin <dan@engrg.uwo.ca>
Subject: Results of the questionaire
To: METLAY@vms.cis.pitt.edu, burdick@hpindl1.hp.com, dan@engrg.uwo.ca,

Here are the questionaire results with my comments added. Some difficulty
was encountered esp. in quantifing things like expertise. Words like some,
lots, expert are relative terms, and I had to do some guessing as to
exactly which category to place people. i.e. These results are not highly
scientific, some errors may be present. The next step (beyond any further
discussion of the topics here, is who voulunteers as co-lead designer/
programmer. Whithout further ado, the results:


This questionaire may reflect the biases of the writers, feel free to
enter your own comments.

GENERAL INFORMATION
- -------------------

Name:_______12 Respondants_____     E-Mail address:______yes for everyone__

What machine(s) and OS(s) are available to you?:
It looks like suns and unix are very popular, however there is some
who only have DOS. Looks like SUN/UNIX with DOS port.

Mac II		2	VMS		2
Sun 3		8	DOS		5
Sun Sparc	2	UNIX	       10
NeXT			OTHER		3
Apple II	2
Silicon Graphics
HP9000
IBM XT/AT	5
VAXen		3
DEC 3100
Amiga 2000

Do you hace access to a PostScript printer?
Most have PostScript access, so we can aim our "preferred" output at
Postscript, but again, text should be available where possible.
YES:	9 	NO:	3

Do you have a C compiler? If yes, specify:______________________
Notice the inherent bias towards C, No Do you program in basic?.
One N/A was recieved from a non-programmer, I wasn't sure if it meant
no compiler, or I'm not programming anyway.
YES:	11 	NO:	0

A C++ compiler? If yes, specify:________________________________
Looks like C++ is out, one YES on C++ preferred C, Theoretically
one could have C++ staements in a #define, but I doubt it would work
well.
YES:	4 	NO:	7

Years and type of C Programming Experience:
Looks like no problem getting people with expertise...
None:	2 	Some:	3 	Lots:	7

Do you have experience writing code to generate PostScript?
In C at least...
None:	9 	Some:	3 	Lots:	0

Do you wish to contribute as a programmer, tester, or as technical
consultant?
Suprisingly few for yes, most had time constraints. Though I'm sure
all of us have school/jobs (or both in my case :-)
Programmer:
YES:		3 	NO:		5 	YES/PROBLEMS:	4
We can assume all programmers will test, however a few people testing
who didn't develop the code is good.
Tester/consultant:		3 

If you would like to program, would you be interested in being lead
or co-lead programmer (you would be responsible for coming up with
the preliminary design)?
I placed reluctant yeses, and time constrained people in the co-lead
position. Due to limited number of programmers, this seems kinda heavy
on the leader side.
YES:	1 	CO:	3 	NO:	3
(The only yes was mine..I guess i'm the voulunteer).
People for Co-lead are:
	Peter Berghold
	Richard Johnson (Design)
	James Perkins
	Bill Morrison (Post Xmas? - Listed as No)

Do you think we should use a co-ordinated programming effort using
software engineering techniques, or should we proceed in an ad hoc
manner with everyone contributing as they have time?
Wide opinions on this one.(note "'s are teken from peoples
responses)...Coordinted wins out:
"Is this project so complex that we need formal techniques?"
"A co-ordinated effort is a *must* (this means software engineering
   techniques)." (Good thing I am in the process of getting a
master's in Software Engineering...)
Most of you specified that it should be fun. I alwyas find that coding
something I like is fun. However if we are to have a good product, there
has to be a certain level of coodination.
Co-ordinated:	7 	Ad-hoc:		2	Both:	1

Do you possess knowledge in the following areas, and to what degree?
As expected a wide variety of backgrounds, For the scale, None, some are
self-explanatory, though I had to guess sometimes as to how a person's
description translated..Lots is up to a bachelor's degree, expert is
a post-graduate degree, or professional employment
Demogrphics and biology are particularily weak.

Astronomy/Astrophysics        -
None:	3 	Some:	2 	Lots:	3 	Expert:	2
Geology                       -
None:	5 	Some:	4 	Lots:	1 	Expert:	0
Archeology                    -
None:	5 	Some:	4 	Lots:	1 	Expert:	0
History/Political Science     -
None:	3 	Some:	6 	Lots:	1 	Expert:	1
Demographics                  -
None:	8 	Some:	2 	Lots:	0 	Expert:	0
Biology                       -
None:	4 	Some:	6 	Lots:	0 	Expert:	0
Fractals/graphics generation  -
None:	3 	Some:	5 	Lots:	2 	Expert:	0

Are there any other general areas of knowledge that you have that you
feel should be considered in generating star/planetary systems (at any 
level of detail) for Traveller/MegaTraveller?
Lots of good stuff here..

Macro-Economics
Anthropolgy
Economics
Military science (twice)
meterorology
graph theory

General Implementation Considerations
- -------------------------------------
(On to the more difficult/subjective questions....)

   System Considerations - This is to provide a general direction for deisgn.
   ---------------------
   If Build 1 is one program that generates strict Traveller/MegaTraveller
   systems, what do you envision Build 2 as being (eg. more functions
   to build 1, a planetary information generator taking input from
   the build 1 program, a trade/X-boat route generator taking input
   from build 1, etc)?
This was probably the least understood question particularily the
concept of "build". Actually Bill's response to his own question was counted
as "confused" - all the people who never really got around to answering the
question  perhaps it is me that is confused? :-)
Planet info:	5 	Maps:	1	Confused:	5

   How should we represent the (as yet unkown) data types?
   [Binary/Record | ASCII] [Single File | Multiple Files]
(This may be a design problem anyway, but preferences from the user is
important - actually the hardest part of design is the specification, as the
user doesn't know what he/she wants, ie. the entire questionaire is really
a ploy on the part of us software engineering types (Bill and Myself):-)
(One Enterprising person already has a basis for the file structure)
Strong opinions on this one, binary was perferred by some solely on space
(ie. they don't have much, ASCII for readability)
Binary:		2 	ASCII:		8 	Both/Either:	2
Unanimously (of those who answered this part) Multiple files.
Single:		0 	Multiple:	9

   Should our production system be one program or a series of programs?
   If a series of programs, how should we break them up (physical, political,
   scale [sector, subsector, system, planet], other)?
One:	1
Series:	9	Scale: 4	Order:	1	Compatability: 1
It looks like series wins out, the method of splitting was in contention.

   What co-ordinate system should we use for sector numbering?
   [Reference|Galaxy Centre|Other]
As far as I know there is no "official" numbering scheme, the sectors are
referred to by name, however computers perfer numbers, and referring to
them by name (index in name file) is actually an "other" sector numbering
scheme)
Reference:	4 	Centre:		2 	Any/Unsure:	4 
Other:		1

   Should we include some data items used by other gaming systems
   (E.g. Galactic Conquest, Exploting Space, Other Suns, and Space Opera)?
I guess the result of this is to include the other system stuff as an
option, perhaps at compile time, so the data files don't have extra fields.
Yes:	7
No:	4

   Should we include religion generation (for example from the world builders 
   handbook), as this may be offensive to some?
Ditto.
Yes:		5
Optional:	4
No:		2


   Capabilities Considerations
   ---------------------------
   The following is a list of capabilities that may eventually be included
   in the final build of our system. On a scale of 1 to 10 (1=soon,
   10=later), please indicate at what stage a certain feature should
   be included into our system. A "1" generally means 'to be included in
   build 1, and a "10" means 'to be included in the last build before
   production - if at all'. Remember to add your own write-ins.

The first numbers are the responses, the last the average. If you
want other statistics (ie. median, std. deviation) calculate them yourself.
I don't guarantee the averages, but the raw data should be correct.

   Map Types  (Note the wide opinion on 3-D)
   ---------               
   Empire maps               : 1 1 2 4 5 5 6 8 8 10 10		5.45
   Sector maps               : 1 1 1 1 1 2 2 5 5 6 10		3.18
   Subsector maps            : 1 1 1 1 1 1 1 1 1 2 10		1.91
   Solar System maps         : 1 1 1 1 1 2 2 3 3 4 5		2.73
   Planetary maps            : 1 1 2 2 2 3 3 4 5 6 6 8		3.58
   Regional (planetary) maps : 1 2.5 3 4 4 5 5 7 8 8 9 10	5.54
   City maps                 : 1 3.5 5 6 7 7 7 10 10 10 10 10	7.21
   Display in '3-D'          : 1 2 3 7 8 9 10 10 10 10 10 10	7.50
   Trade maps                : 9
                                
   Info to be displayed on maps
   ----------------------------
   Number of planets in system : 1 1 1 1 1 1 2 3 6 10		2.70
   Planet Types/Symbols        : 1 1 1 1 1 1 1 1 1 2 5		1.45
      (exotic atmos, planet interdicted, stellar type, etc)
   Black Holes                 : 2 2 2 3 3 4 5 6 7 8 10		4.73
   Neutron Stars               : 2 3 3 4 5 5 6 7 8 10		5.30
   Brown Dwarfs                : 2 3 4 4 5 5 6 6 7 10		5.20
   Other stellar phenomenon    : 2 3 4 4 5 5 5 5 6 6 10		5.00
   Aldebaran Fizz locations    : 1
   (Suggestion for pop-up info). This brings us to a whole new can of worms,
   a graphical interface...Xwindows/sunview, this would be a nice option,
   but difficult to provide for all platforms)

   Trade routes             : 1 1 1 1 2 2 3 3 4 4 4	2.73
   X-Boat routes            : 1 1 1 2 2 2 2 3 4 5 7 8	3.17
   Jump lanes               : 2 2 2 2 2 2 3 3 5 5	2.80
   Military/Scout Bases     : 1 1 1 1 1 1 1 2 2 2 10	2.09
   Government Type          : 1 1 1 1 2 2 2 3 3 10 10	3.27
   Law level                : 1 1 1 1 2 2 2 2 3 5 10	2.73
   Tech level               : 1 1 1 1 1 2 2 2 3 5 10	2.64
   Imperial Sancuaries, etc : 1 1 1 2 2 2 2 3 3 6 10	3.00

   Library Information
   -------------------
(For those of you who voted *no* to "Should we include stuff from other
game systems, all of the non-Traveller/WBH info listed in these sections
came from those other gaming systems..(also we have charts to gernerate
much of this optional info...))
   Number of different *native* lifeforms :1 2 2.5 3 5 5 5 6 7 7 10	4.86
   Xenophobic reaction of population      :1 3 3 4 4 5 5 6 7 7 10	5.00
   Major industries                       :1 2 2 2.5 3 3 3 5 5 6 8	3.68
   Major Corporations                     :1 2 2.5 3 5 5 5 6 6 8 9	4.77
   Exports                                :1 1 2 2 2.5 3 3 4 5 5 5	3.05
   Imports                                :1 1 2 2 2.5 3 3 4 5 5 5	3.05
   Trade duties and taxes                 :1 2 2 3 4 5 5 5 5 7 8	4.27
   Restricted goods                       :1 2 2 2 2 3 3 5 5 5 8	3.45
   Population density                     :1 2 2 2 3 4 4 5 5 5 8	3.73
      (just because it's planet size A and
       population 4 doesn't mean it's not
       crowded).

   Government/Population Information
   ---------------------------------
   Bureaucracy level     :	1 2.5 3 3 3 4 5 5 5 6	3.75
   (how much the government likes to hassle you)
   Loyalty of population :	1 2.5 3 4 4 4 5 5 5 5	3.85
   (to government)
   Crime rate            :	1 3 3 3 4 4 4 5 5 7	3.90
   Punishment level      :	1 2.5 3 4 4 5 5 5 5 6	4.05
   (do they execute you? for jay-walking?)
   Military Status       :	1 2 2 2 2 4 5 5 5 7	3.50
   (at war, pacifistic, etc)
   Repression Index      :	1 2.5 3 3 4 4 5 5 5 6	3.85
   (censorship, unjustified arrests, etc)
   Corruption Index      :     	1 2 2.5 3 4 4 5 5 5 6	3.75
   (corruption of government)
   Government Stability  :     	1 1 3 3 4 4 4 5 5 5	3.50
   (is the same government likely to be in
   power as when we first arrived)
   Average Income        :	1 2 2.5 5 5 5 5 7 8 9	4.95
   (Suggestion to include deviation eg. with a average of Cr2500 per year
   99% of the population still could make only Cr200, perhaps this should be
   median?)
   Current Political/Important Persons: 2.5 4 5 5 6 8 8 9 10	6.39
   Bars, Well-known information centres : 1
   Comments section

   Other Information
   -----------------
   Background radiation level : 2 2 2 2 3 3 3 5 6	3.11
   Meteor Infall              : 2 2 2 3 3 3 3 4 5	3.00
   Solar Energy wavelength curve
   Notable minerals in air or water
   Probability of Ancient habitat


First Build Considerations
- --------------------------

These are general items/capabilities that we may want to consider for the
first (primitive) build of our generation system. Please feel free to add
items at your descretion. If you feel an item should be left for a later
build, please indicate with "LATER". Also, feel free to elaborate on any
item you believe needs more attention.

   System Considerations
   ----------------------------
   Should the first build be one program generating strict (only
   information currently in Traveller/MT/World Builder) systems (This
   would be the frame around which everything else is built)?
Yes:	8	No:	1

   Should we generate our system from scratch or should we use the
   "real" system generator or James Perkins' system generator as a
   *framework* around which to build our system (This means re-writing
   some of the code in those systems to conform to our deign)?
(An interesting note here...james voted in favour of a scratch start)
(one person's note was to use the parts/subroutines in JP's program, or
the Real program as a basis, ie. scratch, using some old stuff.)
Yes:	3
   Real:	0
   Real/3D: 	1
   James P:	1
Yes/Scratch: 5

   If we use either of these systems, should their capabilities by
   included in build 1 or in subsequent builds?
Build 1:	5	Subsequent:	0

   Should the first build be one program unto itself, or should we
   begin with our 'series of program' from the start?
One:	3	Series:	5
   
   How much control over the random generation do we want the user to
   have (UPP(system) level, stellar level, planet level, or more)?
(One person suggested using a constant seed on a pseudo-random number
gerator as data, the problem would be, keeping the order constant ie. if
I generated the solomani rim first, and someone else did the spinward m.
there would be no consistancy, and if we did it in a pre-determined order,
you might wait a while for the data on world 10000.)

Little:	3
Some:	2
Much:	5
 Editing:	2
 Interactive:	2

   Compatibility Considerations
   ----------------------------
   Please indicate if you feel that we should seperate output for each
   "compatibility level", exclusively target one system, or whatever.

(No also include those who don't care if the output is compatable at this level)
   Traveller Compatible:
Yes:	9	No:	1
   MegaTraveller Compatible:
Yes:	10	No:	0
   World Builders Handbook Compatible:
Yes:	8	No:	2
   Other generation system(s):
Yes:	5	No:	5

- ------------------------------

Date: Tue, 21 Nov 89 13:53:05 PST
From: hplabs!joshua@atherton.com (Flame Bait)
Subject: Table handling routines
To: morrison@gatech

[I think people on the Traveller Generation list might find this 
interesting, maybe even useful...]

I'm  working on a set of C subroutines to use and manipulate tables, 
such as are commonly used in FRP and computer games.  I'm posting 
this message for two reasons.  I'd like some beta testers, and I'd like 
some feed back on the features I'm providing, to make sure I'm writing  
something that others will find useful.

Here is the design, please give me any feed back you have:

There will be one public data type (table_t) and a small number of 
function calls:

tb_read:    Read a file containing a table into the program.  These 
	    tables will have a simple format, which will be easy for 
	    a person to create and modify.

tb_tbl:     Prints out the table in troff/tbl format.  Mostly for 
	    debugging.

tb_use:     Makes a dice roll on a table, returning a character string 
            result.

tb_dump*:   Dumps a table in a human unreadable format.

tb_load*:   Loads a previously dumped table.

tb_choose*: Given a number, returns what rolling a number the table 
            would have given you.  (tb_use uses random numbers.)

tb_query*:  Returns information about the table.  Possible queries
            include, a tables name, the sort of dice rolled on it,
            (for multi tables, the list of column names, etc.)
               

Functions marked with a '*' have not yet been implemented; please tell 
me if you think they should be.

Inside the implementation there will be several types of tables, 
although this will be hidden from users.  Each table includes a name, 
the dice roll (ie "1d100", "2d4+1", etc.), the source (p24 of Greyhawk, 
for example), and the information on mapping dice roles to results.

So far I have three types of tables, simple, multi, and change:

Simple tables look like this:
(roll 2d4)
2   first-result
2-6 second-result
7-8 third-result

Multiple tables look like this:

(roll 1d4)
roll   elf dwarf human
1       1    1     0
2       3    3     0 
3-4     4    7     1

And change tables look like this:

(roll 1d8)
light normal heavy   result
 1-4    1-2    1        1
 5-8    3-6    2        2
  -     7-8   3-8       3

Specific questions:

1. New table types?
    a. What other types of tables would you add?

2. New function calls?
    a. Which of the functions marked with a '*' do you want the most?
    b. Which of the functions marked with a '*' do you want the least?
    c. If you want tb_load/tb_dump, please say why.  Is it to load 
       tables as quickly as possible, or to have tables which can not 
       be read by users of the system, or both.  Should this dump format 
       be machine dependent, or does it not matter?
    d. What queries would you support in the query function call?

3. Scripting and Debugging?
    What sort of debugging would you want?

4. Right now, adding a new table type requires a relink, so it can not
   be done "on the fly".  Is this a big problem?  A small one?

5. Right now random numbers are generated with srand/rand.  Should this
   be changeable at run time?  What about at compile time?

(Order all of your suggested improvements, most important first.)

Now about beta testing this stuff:  

The three tables types and three function calls will be ready to beta 
test in two weeks or less.  If you want to be a beta tester, please 
email me.  Besides email address and phone number, please include the 
type of program you will use these routines for. (ie. random monster 
encounter table for AD&D, or Planet generation for Traveller, or 
whatever)  If you use these routines for beta test, I'll expect a copy 
of the program you create, so I can start a regression test suite.  
(This has the nice side effect of you knowing that future releases will 
always support your programs, since they will be used for testing.)  I 
hope to have 5 or 10 beta testers.

For non beta testers who want this stuff:

Just hang out.  In a month or two I'll post how to get copies of version 
1.0 to the same newsgroups that I posted this email.

Joshua Levy
- --------        Quote: "The secret of success is sincerity.  Once you
Addresses:              can fake that you've got it made."
joshua@atherton.com          
{decwrl|sun|hpda}!athertn!joshua    
work:(408)734-9822    home:(415)968-3718

- ------------------------------

End of Traveller System Generation Group Digest
******************************

All opinions and material above is the responsibility of the originator.
Submissions: traveller@dadla.wr.tek.com, or uunet!dadla.wr.tek.com!traveller
Administrator: traveller-request@dadla.wr.tek.com (James Perkins)
The TML is made possible by facilities provided by Tektronix, Inc.

-------- End of TML Messages --------

